Overview

This brief article will highlight the benefits of using the new Dynamic Group Policies (DGP) in Domino 8.5. It will do this by showing the issues an administrator would have to have dealt with pre-8.5 and how DGP addresses those issues.

Pre-DGP

Prior to 8.5 there were only two kinds of policies: organizational and explicit. The former applied to everyone in an organization and so were pretty simple to administer. You just created it, removed it, or modified it. The latter type, explicit policies, had a lot more administrator involvement because they had to be added or removed from individual person documents. There were 5 ways of doing this:
1) Edit the person document directly and add/remove/change the assigned policy.
2) Select one or more person documents in the People view of the directory in the admin client and then right clicking and picking Assign Policy tool.
3) Select one or more person documents in the People view of the directory in the admin client and select Tools->People->Assign Policy.
4) Select one or more group documents in the Groups view of the directory in the admin client and then right clicking and picking Assign Policy tool.
5) Select one or more group documents in the Groups view of the directory in the admin client and select Tools->Groups->Assign Policy.

You could have created your own tool or agents to set the Policy field as well, but only the above mentioned methods will be addressed here.

The first three options are functionally the same. The problem is that say you want to change a policy that you've given to everyone on a certain mail server. You have to find out everyone who has mail on that server and either select all of them and then do option 2 or 3 above. Or you have to change each one individually as in option 1. In both cases you have to hope that you don't miss someone!

But let's say that you have a group defined for all of the users on that mail server, "Corp Mail Server 1". So you could use options 4 or 5 to apply the policy. But wait, what happens if you later add someone to the group? Since they weren't there when you applied the policy initially, they won't get the policy. You would have to re-apply the policy to the whole group. Similarly, if you remove that person from the group, they would still have the policy assigned. In this case, re-applying the policy won't help you, you have to clear the policy out of their person document via options 1, 2, or 3. And if the group, "Corp Mail Server 1" contained subgroups, you would have do to this step for everyone in any of the subgroup(s). That would be a lot of manual work.

Another limitation is that a person can only have one explicit policy assigned to them in their person document. So let's say that you had one explicit policy that dealt with only security settings and another explicit policy that had only desktop settings. Since a user can only have one explicit policy at a time, if you wanted a user to have both settings you would have to create a third policy that combined the security settings of the former with the desktop settings of the latter. In effect, you would have to have an explicit policy for every combination of settings that you wanted. This would result in a proliferation of policies.

DGP to the rescue!

In the first three cases above, instead of a user being assigned a policy, the policy contains the list of users to whom it applies. You can easily add or remove people right from one place, the policy. You don't have to open up multiple documents. Additionally, if you use the Home Mail server auto-populated group option you wouldn't have to figure out who is on the mail server at all!

But where DGP really helps of course is with dealing with users on a group basis. If a person is removed from a group, they will automatically no longer have that policy assigned to them. Similarly, if they are added to a group, they will get the policy for that group. And if subgroups are involved, you can quickly remove all of the people from a group without having to worry about what subgroups that they may additionally contain.

Additionally, since a user can be in more than one group at a time you could have one group called "Security Settings group" and another called "Desktop Settings group" each which are assigned to Security Policy and Desktop Policy respectively. The user could be added to both groups and now will receive both of those settings since they will be merged into their final effective policy. If more than one group has a particular setting, then precedence will come into play and that is described in another Wiki article here domino-policy-precedence-explained So creating a third policy wouldn't be needed any longer!

Now it might be argued that instead of creating multiple policy documents, the effort has been replaced with creating multiple group documents. But the difference is that when you want to make a change you would only have to potentially change 1 group document instead of having to change multiple person documents. An additional benefit is that when the group documents themselves are automatically maintained either through Home Server groups or other group management systems, two layers of administrative headaches have been removed. Say for example that you have a company NSF application where you keep track of employees that are on vacation. In such an application, when a person logs their vacation time they will automatically be added to a group of "Out of Office" people. That group could then be used to control some mail settings that could be relaxed during the time they were away.

Conclusion

Dynamic Group Policies are a great way to cut down on the workload of the administrator. And they can also be used to provide more flexibility than explicit policies alone. When combined with Home Server groups or other methods where groups are automatically generated, an administrator's workload can be reduced even further. So start using Dynamic Group Policies today and reduce your Total Cost of Ownership!